Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@storage/src/main/java/org/zstack/storage/snapshot/group/VolumeSnapshotGroupTreeBuilder.java`:
- Around line 213-229: The current winner-selection loop in
VolumeSnapshotGroupTreeBuilder uses the iteration order of the votes Map to pick
a winner on ties, causing nondeterministic parentGroupUuid; update the tie-break
so ties are resolved deterministically (e.g., compare group UUID strings
lexicographically and choose the smallest). Specifically, in the loop that
inspects votes (variable votes, winner, top, tie), when e.getValue() == top
instead of setting tie true only, compare e.getKey() with the current winner and
set winner to the lexicographically smaller UUID to ensure stable selection;
keep logging of tied votes but ensure the returned winner is deterministic.

In
`@storage/src/main/java/org/zstack/storage/snapshot/VolumeSnapshotManagerImpl.java`:
- Around line 1369-1384: The reply handler in VolumeSnapshotManagerImpl
currently only checks reply.getInventories() for null but not for an empty list,
letting the flow continue and potentially return groupTrees for queries that
should be filtered out; update the early-exit to return when
reply.getInventories() is null or empty (e.g., check
reply.getInventories().isEmpty()), so the subsequent calls to
groupTreeBuilder.extractVolumeUuidCondition(msg),
groupTreeBuilder.findRootVmUuid(volumeUuid) and
reply.setGroupTrees(groupTreeBuilder.buildForVm(vmInstanceUuid)) are only
executed when inventories contain results.

In
`@storage/src/main/java/org/zstack/storage/snapshot/VolumeSnapshotTreeBase.java`:
- Around line 1436-1441: The code in VolumeSnapshotTreeBase calls
dbf.removeByPrimaryKey(volumeSnapshotInv.getGroupUuid(),
VolumeSnapshotGroupVO.class) twice; remove the duplicate call so the group is
only deleted once. Locate the block where logger.debug(...),
vidm.deleteArchiveVmInstanceResourceMetadataGroup(volumeSnapshotInv.getGroupUuid()),
and the two dbf.removeByPrimaryKey(...) calls occur and delete the redundant
second dbf.removeByPrimaryKey invocation that uses
volumeSnapshotInv.getGroupUuid() and VolumeSnapshotGroupVO.class.
- Around line 2177-2185: Remove the unresolved merge markers (<<<<<<<, =======,
>>>>>>>) and merge the two branches: use the correctly scoped collection (use
groupsToDelete) and perform all three actions when it's non-empty — call
vidm.deleteArchiveVmInstanceResourceMetadataGroup for each UUID, invoke
cleanVmHostBackupFilesForGroup(groupsToDelete) to clean backup files, and then
call dbf.removeByPrimaryKeys(groupsToDelete, VolumeSnapshotGroupVO.class);
ensure you reference the existing methods
deleteArchiveVmInstanceResourceMetadataGroup, cleanVmHostBackupFilesForGroup,
and dbf.removeByPrimaryKeys and remove any mention of the undefined
groupUuids/touchedGroupUuids variables.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@storage/src/main/java/org/zstack/storage/snapshot/group/VolumeSnapshotGroupTreeBuilder.java`:
- Around line 267-281: In markCurrent (class VolumeSnapshotGroupTreeBuilder) the
current selection is non-deterministic when all
VolumeSnapshotGroupTreeInventory.getCreateDate() values are null because newest
falls back to the first Map iteration; modify markCurrent to first detect
whether any node has a non-null createDate and only setNewest/setCurrent when at
least one non-null exists OR implement a stable tie-breaker: compare createDate
first, and when both are null or equal use a deterministic key such as
node.getUuid() (lexicographic ascending) to choose newest before calling
setCurrent(true) on the chosen VolumeSnapshotGroupTreeInventory; ensure you
reference groupNodeMap and update only the single chosen node.
- Around line 180-193: 在 linkParents/assembleForest 的父子组装流程中缺少有向环检测，可能产生循环依赖；在把
parentGroupUuid 写回节点（方法 linkParents 使用 resolveParentGroupUuid）并在 assembleForest
挂子节点前先对由 parentMap/snapToGroup/refsByGroup 导出的有向图做环检测（例如使用 DFS 标记或 Kahn
拓扑排序），一旦检测到环就断开环中一条父边，按照建议规则选出要断开的边（比如在环内移除指向 createDate 较新的节点的父边，或在相同时间取 uuid
较大者断开），更新相应节点的 parentGroupUuid（和相关映射），然后再安全地调用 assembleForest 构建树。